There is a single sign-on (hereinafter, referred to as an “SSO”) as a technique of performing authentication collaboration capable of using a plurality of applications or services by a single authentication procedure. In the SSO, there are many cases in which authentications included in a plurality of applications are integrated in a single domain such as the Intranet of one company.
However, in recent years, the SSO is required between different domains (which means ‘between different WWW servers’, and hereinafter referred to as a “cross domain”). The reasons may include an increase in corporate marriage or merge, overseas development, and the like, and an outsourcing by software as a service (SaaS) of raised cloud computing or the like.
However, in implementing the cross domain SSO, there is a problem in that a great deal of time and effort are required to share an authentication result. The main problems are the following two points.
A first problem lies in that since a use of an HTTP cookie is limited to a single domain, it is difficult to share an authentication result between domains using an HTTP cookie. A second problem lies in that since an SSO scheme of an access management product employed by each domain differs according to a vender, it is difficult to simply introduce, and it is necessary to prepare a separate measure.
In order to solve the above problems, there is a demand for standardization of an SSO. As one of representative standard techniques to comply with a request, there is a security assertion markup language (SAML) made by an organization for the advancement of structured information standards (OASIS) which is a non-profitable organization.
The SAML is a specification that defines an expression form of information related to an authentication, an authorization, and an attribute and transmission and reception procedures, and is systematically specified so that an implementation can be made in various forms according to the purpose. Main entities include three of an identity provider (hereinafter, referred to as an “IDP” or “ID provider”), a service provider (hereinafter, referred to as an “SP” or “service provider”), and a user and the SSO is implemented such that the service provider trusts in an authentication result issued by the ID provider.
When the user starts the SSO based on the SAML, it is generally necessary to prepare the following two points in advance. Firstly, a relation of trust needs to be constructed through information exchange or an agreement in a business or a technology between the service provider and the ID provider. Secondly, each user has an individual account for each service provider, and thus the individual SP account needs to collaborate with an account of the ID provider in advance (hereinafter, referred to as “account collaboration”). In a state in which advance preparation such as construction of the relation of trust and prior account collaboration is not finished, it is difficult for the user to start the SSO.
After the advance preparation, the SSO is implemented by the following procedures (1) to (6). Here, an SSO procedure of a service provider start model using a user terminal will be described.
(1) The user requests the service provider to provide a service.
(2) The service provider transmits an authentication request to the ID provider through a user side terminal since the user is not authenticated yet.
(3) The ID provider performs authentication on the user by a certain procedure, and generates an authentication assertion. The SAML does not specify an authentication means, and specifies only a system in which the authentication assertion is transmitted to the service provider. The authentication assertion includes information representing a way of generating the type of authentication means or a credential since the service provider determines whether or not the service provider can trust in an authentication result.
(4) The ID provider transmits the authentication result including the generated authentication assertion to the service provider through the user terminal.
(5) The service provider decides whether or not a service is to be provided based on the authentication result of the ID provider.
(6) The user is provided with a service from the service provider.
Further, in connection with the origination point from which the user makes an SSO request, in the SAML, two models, that is, a service provider start model (hereinafter, referred to as an “SP start model”) and an ID provider start model (hereinafter, referred to as an “IDP start model”) are defined. The SP start model follows the SSO procedure, and is a model in which an SSP request starts when the user accesses the SP, and the SP transmits an authentication request based on the SAML.
The IDP start model is a model in which the process starts when the user terminal requests the ID provider to provide the service of the service provider in the SSO procedure (1). Thus, the process of (3) to (6) is performed subsequently to the procedure (1) without performing the SSO procedure (2).
As described above, in the SSO based on the SAML, as the ID provider performs a single authentication procedure, the user can use a plurality of services without an additional authentication procedure.
However, the SSO based on the SAML is mere a part such as “use” of identity in an overall life cycle of an identity. As described above, when the SSO starts, it is necessary to perform account collaboration, and in order to perform account collaboration, a technique of comprehensively collaborating management such as registration, change, deletion, reissue, and temporary suspension of an identity between the service provider and the ID provider is required.
As a technique for automating registration, change, deletion, reissue, and temporary suspension of an identity, there is account provisioning, and as a standard technique thereof, there is a service provisioning markup language (SPML).
Meanwhile, there has been known a data processing system that actively executes account collaboration as a part of the SSO in a state in which the advance preparation of the account collaboration is not finished. Typically, when the SSO starts in a state in which the user's account is not registered to the service provider side, that is, in a state in which account collaboration is not performed, an error occurs.
However, according to this data processing system, the account collaboration can be actively executed as a part of the SSO even in the above-described state. Specifically, after the service provider receives a service request from the user, the service provider checks that information sufficient register the user's account is not held. After checking, the service provider requests the ID provider to provide a user attribute, and the ID provider provides the service provider with a desired user attribute. As a result, the data processing system executes account registration and collaboration in the process of the SSO.
However, for example, when a predetermined user uses the SaaS in a company, a management department needs to collectively perform prior account registration and account collaboration on the service provider. Alternatively, a service provider use request procedure is performed through a series of authorization flow by each user at an arbitrary timing, and then a management department performs prior account registration and collaboration related to the user who made the request on the service provider. After the preliminary process is performed, the user can use the service provided by the service provider.
Here, when the preliminary process of the former is performed, since account registration and collaboration need not be executed in the process of the SSO, it is not related to the above-described data processing system. Meanwhile, when the authorization flow of the latter is performed, a great deal of time and effort are required since a lot of manpower is necessary such as seniors and a management department of an organizational to which the user belongs as well as the user. In addition, since the management department does not collectively perform account registration and collaboration, a manual work is necessary, and a burden is great. Thus, efficiency and convenience are bad.
In the SaaS or the like, there is an advantage that it can be used when desired. However, in the case of the authorization flow of the latter, a manual work occurs, and a burden is great, and thus it is difficult to have the advantage. For this reason, in a system in which account registration and collaboration are executed in the process of the SSO, it is desirable to include a seamless system capable of deciding whether or not a service can be used without involving a manual operation.
However, in order to implement this system, it is necessary to modify the ID provider having the SAML function, and the introduction cost is high.
In order to achieve the object of the present invention, there is provided an authentication collaboration system and an ID provider device, which are easy to introduce since the ID provider device needs not be modified and can decide whether or not a service can be used without a manual operation when account registration and collaboration are executed in the process of the SSO.